Setting Up a Collaborative Workspace

This topic describes the various ways to set up a Collaborative Workspace.

Setting up an application development environment where multiple developers come together to develop applications has its own needs and challenges. Through Collaborative Workspace (CWS), Process Platform provides an application development environment where several developers can work together on the same software deliverable.

CWS accommodates all the requirements of a team application development. It provides a single interface at design time to develop the application content. It facilitates easy creation and modification of the documents that form the building blocks of an application. All developers developing an application can access their own workspace through a browser on any computer, and work simultaneously on the same application content.

This topic discusses scenarios in which you can set up Process Platform development teams in CWS to collaboratively develop an application. The following scenarios are discussed as most probable options:

Separate Developer Stations (each one having a Workspace) - Configured to a Source Control Management (SCM) system
Separate Workspaces - Central Development Server - Configured to an SCM system
Single Workspace - Central Development Server - Configured to an SCM system
Single Workspace - Central Development Server - Not configured to an SCM system

Note:
This is an exemplary list of scenarios. There may be more scenarios depending upon the development requirements. The following sections discuss the setup of each scenario in detail.

Separate Developer Stations (each one having a Workspace) - Configured to an SCM System

A developer has Process Platform installed on the individual development station and has an individual workspace. Each workspace is configured to a common SCM system. Developers can develop content in their local machines (within their respective workspaces). They can either get update from SCM system or make their change set (updated development content) available to the SCM system through the option available in the workspace. Build/deployment, test, and production activities are carried out on separate servers connected to the SCM system. The features of this setup are:

One Process Platform installation per developer
Total isolation of development content
Application content from the workspace is stored in the file system on the local computer
Application content is shared with other developers through the SCM system
Versions of the developed content is maintained in SCM system
If required, remove workspace without removing content from the SCM system

The following illustration may help you understand this type of development setup:

Separate Workspaces - Central Development Server - Configured to an SCM System

Each developer connects to a private workspace on the Central Development Server. The Central Development Server is linked to the SCM system. Developers can add and modify content within their respective workspaces. They can either receive updated content from the SCM system or make their change set (updated development content) available to the SCM system through the option available in their workspace. The build/deployment server gets all the updates from the SCM system. On demand or on regular intervals, the build master incorporates all changes to this workspace and packages all projects. This results in creation of application packages that can be loaded on test or production servers for testing or production.

The salient features of this setup are:

Single Process Platform installation supports multiple development workspaces
Total isolation of development content
Application content is shared with other developers through the SCM system
Share workspaces - developers can be a part of more than one workspace. This provision facilitates functional grouping of developers within an organization. For example, all business users can work in one workspace.
Maintain versions of the developed content
If required, remove workspace without removing content from the SCM system

The following illustration may help you understand this type of development setup:

Single Workspace - Central Development Server - Configured to an SCM System

All developers will connect to a single workspace, where a single instance of Process Platform is installed on a Central Development Server. The development server is configured to an SCM system. Application building and packaging happens on the Deployment Server and the package is delivered to separate test and production servers.

This scenario indicates that independent developers can work within the same workspace on a central server which is configured to an SCM system. The following illustration may help you understand this type of development setup:

Single Workspace - Central Development Server - Not Configured to an SCM System

All developers will connect to a single workspace, where a single instance of Process Platform is installed on a Central Development Server. The only difference between the previous mode and this mode is that it is not configured to an SCM. Application building and packaging happens on the Deployment Server and the application package is delivered to separate test and production servers.

This scenario indicates that independent developers can work within the same workspace on a Central Development Server. The following illustration may help you understand this type of development setup:

This scenario poses the following risks:

Absence of version control, and therefore no provision to restore earlier version(s) of development, if required
Deleting the workspace will delete all the content

Setup CWS Development Environment

The following high-level topics contain information that help you setup CWS development environment:

Creating a Workspace

Creating a Solution.

Important

Creating or using a solution is not a mandatory option. This feature has been provided in order to enable users to logically group their projects that exist in the same workspace, if required. Hence, wherever a procedure on using a solution is mentioned in the documentation, the procedure has to be followed only if a solution was used in the application. Else, the solution part in the procedure can be ignored.